2026-06-09 Harness Engineering 拷问复盘
本轮概览
- 知识点：Harness Engineering
- 模块：5. AI Agent 架构
- 分数：84
- 是否过关：是
- 来源卡片：[[../5. AI Agent 架构/Harness Engineering.md|Harness Engineering]]
第 1 题
题目：
你先用一句话定义什么是 Harness Engineering，再说明它和 Prompt Engineering、Context Engineering 的边界分别是什么。要求你不要只讲概念，要顺带回答一个核心判断：为什么到了长链路、低容错、可执行的商业场景，主要矛盾会从 Prompt/Context 转移到 Harness？
你的回答：
你能抓住业界公式 Agent = Model + Harness，并说明除了模型本身之外，提示词设计、工具调用、记忆与状态、编排、观测评估、成本时延、约束恢复都属于 Harness。对 Prompt 和 Context 的边界也答到了，能说明 Prompt 更偏指令设计，Context 更偏信息供给与组织；对“为什么商业场景主要矛盾转到 Harness”也给出了稳定、安全、可观测执行的理由。
缺失点：
边界还可以更锋利。最值得你固定下来的短句是：Prompt 是指令层，Context 是供给层，Harness 是执行控制层。 另外你提到了限流、降级、熔断、缓存、日志、鉴权，这些很好，但还可以再补一句：商业场景的核心不是“让模型答得更像”，而是“让系统在真实执行中不乱做、做得对、出错能恢复”。
推荐答案：
Harness Engineering 就是围绕大模型外侧搭建一整套可执行系统，让 Agent 具备持续执行、持续校验、持续恢复的能力。Prompt Engineering 解决“怎么把指令说清楚”，Context Engineering 解决“该给模型什么信息、什么时候给”，Harness Engineering 解决“系统怎么把这次推理变成稳定、安全、可观测的执行链路”。到了长链路、低容错、可执行的商业场景，瓶颈不再只是模型一次输出质量，而是工具能不能安全调用、状态能不能持续推进、错误能不能及时发现和恢复，所以主要矛盾自然会转到 Harness。
项目口径：
在我的项目里，我不会把 Agent 理解成“模型加几个 Prompt”，而是“模型外面包了一整套 Harness”。模型负责理解用户意图，Harness 负责上下文注入、工具白名单、状态推进、鉴权校验、日志观测和失败恢复。真正决定能不能上线的，往往不是模型本身，而是这套 Harness 是否能保证高风险业务不乱执行。
第 2 题
题目：
如果让你把 Harness Engineering 拆成一个可落地的工程分层，你会怎么分？你至少讲出 5 层，并且每一层都要回答两个点：它解决什么问题、如果这一层没设计好，线上会出什么故障。尽量结合你自己的项目口径来答，不要只背抽象定义。
你的回答：
你分出了信息边界层、工具系统层、编排执行层、记忆与状态层、观测和评估层、约束校验与可恢复层六层结构，而且大部分都能落到项目里，比如不同 Advisor 的提示词、工具防死循环、参数清洗、高危二次确认、白名单、超时熔断、多意图多步骤执行、Redis 任务状态、混沌测试、RAG 召回率测试等，整体是比较扎实的。
缺失点：
这题的扣分点主要在“线上故障”没有逐层讲透。面试官如果继续追问，你需要能更快说出每层没做好会发生什么，例如：信息边界层失控会导致上下文污染和越权回答；工具系统层失控会导致误调高危工具和参数脏写；编排层失控会导致跳步、漏步、重复执行；记忆层失控会导致任务状态丢失或脏状态续跑；观测层失控会导致故障发现过晚；恢复层失控会导致超时后重复提交、半成功半失败无法收敛。
推荐答案：
我通常把 Harness 拆成六层。信息边界层解决“该给模型什么目标和边界”，没做好会导致上下文污染和角色漂移；工具系统层解决“模型能调用什么能力、怎么安全调用”，没做好会导致误调用、高危越权、死循环；编排执行层解决“多步骤任务按什么轨道推进”，没做好会导致跳步、漏步、顺序错误；记忆与状态层解决“当前状态和中间产物怎么管”，没做好会导致长任务中断后无法恢复或带着脏状态继续执行；观测与评估层解决“怎么知道系统是否做对、性能是否退化”，没做好会导致故障只能靠用户反馈发现；约束与恢复层解决“出错后如何限损和收敛”，没做好会导致超时重试把错误放大成事故。
项目口径：
在 苍穹外卖 AI 客服 里，我会把这六层映射成具体工程件：Advisor 链和提示词模板属于信息边界层；工具白名单、签名检测、超时熔断属于工具系统层；多意图多步骤执行器属于编排层；Redis 短期状态和任务中间产物属于记忆与状态层；日志、混沌测试、RAG 召回指标属于观测评估层；二次确认、鉴权、状态机校验、降级策略属于约束与恢复层。
第 3 题
题目：
现在把 Harness Engineering 放到你的 苍穹外卖 AI 客服 项目里，讲一个完整链路：假设用户发起一个高风险、长链路、低容错的请求，比如退款、退单、催单这类场景，你要从 用户输入 -> 意图识别 -> 上下文/记忆注入 -> 工具选择与执行 -> 状态推进 -> 校验与恢复 -> 最终响应 这一整条链路往下讲。重点回答三个问题：
- 为什么这个场景不能只靠一句 Prompt 搞定？
- 你的 Harness 在每个关键节点分别做了什么兜底？
- 如果模型判断错了、工具超时了、或者状态和数据库真实状态不一致，你怎么保证系统不会乱执行？
你的回答：
你已经讲出了主链路：先做退款意图识别和用户确认，再注入短期和长期记忆、生成工具白名单、走退款规则 RAG、装配工具执行、加超时和重复调用熔断、进入后端做鉴权和状态机校验，完成后异步写入记忆系统，并区分长期记忆是否落库。你也明确说了这类场景不能只靠单 Prompt，因为这里真正难的是执行时问题，不是一次对话输出质量。
缺失点：
这一题你的回答方向是对的，但还不够“事故级严谨”。你对“模型判断错了”和“数据库状态不一致”回答得偏短，基本只提了后端强校验。更完整的答法应该补出：高风险动作必须以后端权限、订单状态机、幂等键、结果回查为准；模型只能给出调用倾向，不能直接决定执行；工具超时后不是默认重试到底，而是进入熔断或人工确认；如果状态不一致，要以数据库真实状态为准并返回可解释错误，而不是让 Agent 自行猜测补救。
推荐答案：
以退款场景为例，用户输入后先做意图识别和参数抽取，如果涉及高风险操作，先做人机确认，再根据当前任务生成最小工具白名单，并把退款规则、订单状态、必要上下文注入进去。随后进入工具执行阶段，Harness 会做参数校验、签名去重、超时控制和最大轮次限制。真正执行到后端时，还要经过鉴权、状态机校验、幂等控制和业务规则检查。执行完成后，不是只看模型说成功，而是要看工具返回和数据库真实状态是否一致；如果不一致，就以后端结果为准，并触发降级、告警或人工兜底。这里模型只是推理器，真正保证不乱执行的是 Harness 加后端业务校验。
项目口径：
我在项目里对高风险场景的设计原则是：模型只负责“理解”和“建议调用”，不负责“拍板执行”。真正的执行权在 Harness 和后端业务系统手里。比如退款这类操作，前面要有人机确认，中间要有最小工具集和超时熔断，后面要有鉴权、状态机、幂等、日志审计和结果回查。这样即使模型误判、工具超时或状态脏读，系统也只是“不执行”或者“进入降级”，而不是直接把错误动作做出去。
下次复习动作
- 固定一句边界表达：
Prompt 是指令层，Context 是供给层，Harness 是执行控制层。 - 把六层结构各自对应的“线上故障表现”背成一句话，避免面试里只会讲职责不会讲事故。
- 针对退款/退单这类高风险场景，补齐
幂等控制 -> 结果回查 -> 数据库真实状态兜底 -> 人工确认/降级这条答辩链。